IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media that it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
The UMTS (Universal Mobile Telecommunications System) is a third generation wireless system designed to provide higher data rates and enhanced services to subscribers. UMTS is a successor to the Global System for Mobile Communications (GSM), with an important evolutionary step between GSM and UMTS being the General Packet Radio Service (GPRS). GPRS introduces packet switching into the GSM core network and allows direct access to packet data networks (PDNs). This enables high-data rate packets switch transmissions well beyond the 64 kbps limit of ISDN through the GSM call network, which is a necessity for UMTS data transmission rates of up to 2 Mbps. UMTS is standardised by the 3rd Generation Partnership Project (3GPP) which is a conglomeration of regional standards bodies such as the European Telecommunication Standards Institute (ETSI), the Association of Radio Industry Businesses (ARIB) and others. See 3GPP TS 23.002 for more details.
The UMTS architecture includes a subsystem known as the IP Multimedia Subsystem (IMS) for supporting traditional telephony as well as new IP multimedia services (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7). IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. The 3GPP has chosen SIP for signalling between a User Equipment (UE) and the IMS as well as between the components within the IMS.
Specific details of the operation of the UMTS communications network and of the various components within such a network can be found from the Technical Specifications for UMTS that are available from http://www.3gpp.org. Further details of the use of SIP within UMTS can be found from the 3GPP Technical Specification TS 24.228 V5.8.0 (2004-03).
FIG. 1 of the accompanying drawings illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
A user registers with the IMS using the specified SIP REGISTER method. This is a mechanism for attaching to the IMS and announcing to the IMS the address at which a SIP user identity can be reached. In 3GPP, when a SIP terminal performs a registration, the IMS authenticates the user, and allocates a S-CSCF to that user from the set of available S-CSCFs. Whilst the criteria for allocating S-CSCFs is not specified by 3GPP, these may include load sharing and service requirements. It is noted that the allocation of an S-CSCF is key to controlling (and charging for) user access to IMS-based services. Operators may provide a mechanism for preventing direct user-to-user SIP sessions which would otherwise bypass the S-CSCF.
During the registration process, it is the responsibility of the I-CSCF to select an S-CSCF if a S-CSCF is not already selected. The I-CSCF receives the required S-CSCF capabilities from the home network's Home Subscriber Server (HSS), and selects an appropriate S-CSCF based on the received capabilities. (It is noted that S-CSCF allocation is also carried out for a user by the I-CSCF in the case where the user is called by another party, and the user is not currently allocated an S-CSCF.) When a registered user subsequently sends a session request to the IMS, the P-CSCF is able to forward the request to the selected S-CSCF based on information received from the S-CSCF during the registration process.
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end-users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be “linked in” during a SIP Session establishment. Different IFCs may be applied to different call cases. The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's User Profile. Certain Application Servers will perform actions dependent upon subscriber identities (either the called or calling subscriber, whichever is “owned” by the network controlling the Application Server). For example, in the case of call forwarding, the appropriate (terminating) application server will determine the new terminating party to which a call to a given subscriber will be forwarded. In the case that an IFC indicates that a SIP message received at the S-CSCF should be forwarded to a particular SIP AS, that AS is added into the message path. Once the SIP message is returned by the AS to the S-CSCF, it is forwarded on towards its final destination, or forwarded to another AS if this is indicated in the IFCs.
As appreciated by the applicant, the IMS does not specify any procedure by which an IMS node advertises the adjacent nodes (or far end nodes) about a temporary unavailability due to, for example, a restart, local maintenance operations such as software (SW) upgrades, and so on, and the later recovery.
The lack of such a procedure can cause some interference in the usual function of the applications involved.
It is desirable to address the above-identified issue.
The following is a list of some of the previously-considered procedures for recovery situations:                GSM Restoration procedures: In this specification it is described the methods by means of which nodes like HLR, VLR, SGSN, GGSN restore user data after their loss of corruption. See “3rd Generation Partnership Project; Technical Specification Group Core Network; Restoration procedures (Release 6)” (3GPP TS 23.007 V6.1.0).        Radius Charging ON-OFF: When a Radius Charging client recovers from an unavailability situation, it advertises the charging server about the event so that the charging server closes all sessions related with the affected client (i.e. those charging sessions opened for users which use the affected client). See RFC 2865 “Remote Authentication Dial In User Service (RADIUS)”.        MTP 3 Restart: once the MTP 3 layer recovers from a restart (unavailability), it begins an advertising procedure toward the adjacent nodes, so that they can reconfigure their routing tables accordingly and notifies their respective users about the event for taking the proper actions. See “Specifications of Signalling System No. 7-Message transfer part; Signalling network functions and messages”, ITU-T Recommendation Q.704.        SCCP Restart: similar to the MTP 3 Restart but at SCCP level and advertising only the concerned subsystems.        M3UA Restart: Equivalent to the MTP 3 Restart but for SIGTRAN.        Diameter peer restart: This is detected with the DWR/DWA messages specified in IETF RFC 3588.        Diameter application restart: This is indicated with the Origin-State-Id AVP specified in IETF RFC 3588.        
It is desirable to address the above-identified issue.